🤔 @Kielek IIRC the conversation on the SIG with @carlosalberto was to follow Java in this regard, i.e.: use _ENABLED instead. These will be very similar environment variables and it will be nice to have similar languages following the same pattern.

@carlosalberto what are your thoughts in this regard?

Issue regarding bool env vars in this project: #2090

@Kielek why going with the _DISABLED instead of _ENABLED with reversed defaults? I ask because Java uses _ENABLED instead _DISABLED. See https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/#enable-only-specific-instrumentation

See: #2090

@pellared I'm aware of that but I'm under the impression that at the SIG meeting, we talked with Carlos about following the Java precedent in this case.

@pellared I'm aware of that but I'm under the impression that at the SIG meeting, we talked with Carlos about following the Java precedent in this case.

Java is still a little different. We have not discussed _DISABLED vs _ENABLED with @carlosalberto. I lean towards spec recommendation, but I will not fight for it 😄

@pellared neither I will fight for it :), but, I would prefer to commit the version that has the smaller chance of having to be reverted later.

So, what are we going forward with in the end? 😬

Even, I feel it is easier for customers to use _ENABLED in the environment variables. We could hold the merge of the PR till SIG meeting for a detailed discussion.

Reasons why I lean towards _DISABLED

1. Follows OTel spec recommendation
2. Same approach as with OTEL_SDK_DISABLED
3. I have not found any env var in the OTel spec which defaults to true
4. I think that the convention with leaning towards using false as the default value makes sense as:
   • "[Users] do not need to go look up documentation elsewhere about the value, they just know because that [false] is the OTel default." from Definition of boolean environment variables on the SDK opentelemetry-specification#2755 (comment)
   • it simplifies discussions like this one 😉

I think this approach has smaller chances in getting changed as it is based on OTel spec. That is why I would prefer merging the current version.